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Abstract 

A  new  transaction  model  for  multilevel- secure  databases  which  use  the  replicated 
architecture  is  presented.  A  basic  concurrency  control  algorithm  and  two  variations  are 
given  based  on  this  transaction  model.  We  also  present  new  correctness  criteria  for 
multilevel- secure  databases  which  use  the  replicated  architecture.  Based  on  this  criteria,  we 
prove  that  our  algorithms  are  correct. 
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1.  INTRODUCTION 

There  are  several  approaches  for  multilevel  database  systems  which  protect  classified 
information  from  unauthorized  users  based  on  the  classification  of  the  data  and  the  clear¬ 
ances  of  the  users.  One,  the  integrity  lock  approach  [5],  attempts  to  combine  encryption 
techniques  with  off-the-shelf  database  management  systems.  The  trusted  frontend  applies  an 
encrypted  check  sum  to  data  in  untrusted  backend  databases.  Another,  the  kernel i zed 
approach  [11],  relies  on  decomposing  the  multilevel  database  into  single  level  databases 
which  are  stored  separately,  under  the  control  of  a  security  kernel  enforcing  a  mandatory 
access  control  policy. 
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The  integrity  lock  approach  is  computationally  intensive  and  has  a  potential  covert 
channel.  The  kemelized  approach  can  yield  reduced  performance  due  to  the  need  for  recom¬ 
bining  single  level  data  to  produce  multilevel  data.  Motivated  by  performance  concerns,  a 
replicated  architecture  approach  has  been  proposed. 

The  replicated  architecture  approach  [6]  uses  a  physically  distinct  backend  database 
management  system  for  each  security  level.  Each  backend  database  contains  information  at 
a  given  security  level  and  all  data  from  lower  security  levels.  The  system  security  is  assured 
by  a  trusted  frontend  which  permits  a  user  to  access  only  the  backend  database  system 
which  matches  his/her  security  level. 

The  SINTRA1  database  system,  which  is  currently  being  prototyped  at  the  Naval 
Research  Laboratory,  is  a  multilevel  trusted  database  management  system  based  on  this 
replicated  architecture.  The  replicated  architecture  system  contains  a  separate  database  sys¬ 
tem  for  each  security  level.  The  database  at  each  security  level  contains  data  at  its  own  secu¬ 
rity  level,  and  replicated  data  from  lower  security  levels. 

The  SINTRA  database  system  consists  of  one  trusted  front  end  (TFE)  and  several 
untrusted  backend  database  systems  (UBD).  The  role  of  the  TFE  includes  user  authentica¬ 
tion,  directing  user  queries  to  the  backend,  maintaining  data  consistency  among  backends, 
etc.  Each  UBD  can  be  any  commercial  off-the-shelf  database  system.  Figure  1  illustrates 
the  SINTRA  architecture. 

In  the  SINTRA  project,  we  make  the  following  assumptions: 

(1)  All  UBD  use  the  same  database  query  language  (e.g.,  SQL). 

(2)  The  TFE  changes  the  database  states  of  the  UBD  only  through  database  queries. 

(3)  Each  UBD  performs  some  type  of  scheduling  which  produces  a  serializable  and  recov¬ 
erable  history. 

1.1.  Merits  and  Problems  for  the  Replicated  Architecture 

At  first  glance,  a  database  mangement  system  for  each  security  level  may  seem  exces¬ 
sive.  However,  we  think  this  approach  has  the  following  merits: 

•  The  security  policy  can  be  easily  enforced  by  carefully  designing  interfaces  among  dif¬ 
ferent  database  systems. 

•  Development  cost  can  be  reduced  because  commercial  database  systems  for  backend 
computers  are  widely  available. 

•  The  amount  of  trusted  software  can  be  minimized. 

•  Performance  can  be  improved  by  using  optimization  and  parallelization  techniques 
which  have  been  developed  for  conventional  databases.  This  is  the  case  because  the 
replicated  architecture  uses  conventional  database  systems  as  backend  database  sys¬ 
tems,  and  uniprocessor  or  multiprocessor  computers  can  be  chosen  as  backend  comput¬ 
ers  without  affecting  the  security  policy. 

Despite  the  above  advantages,  the  replicated  architecture  has  a  unique  problem.  Since  each 
UBD  in  a  replicated  architecture  contains  data  from  lower  levels,  update  transactions  have 


1.  Secure  INformation  Through  Replicated  Architecture 
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Figure  1:  The  SINTRA  Architecture. 

to  be  propagated  up  to  higher  security  level  databases.  There  are  some  problems  which  are 
related  to  this  propagation. 

[a]  Since  lower  level  update  transactions  propagate  to  higher  level  databases,  high-level 
databases  can  be  overloaded  with  lower  level  update  transactions.  This  creates  prob¬ 
lems  such  as  slow  response  to  the  request  of  a  high-level  user  and  longer  propagation 
time  for  lower  level  update  transactions. 

[b]  The  propagation  of  update  transactions  has  to  be  carefully  controlled.  If  the  propaga¬ 
tion  of  update  transactions  is  not  carefully  controlled,  inconsistent  database  states 
among  backend  databases  can  be  created.  Consider  this  example.  Two  confidential 
level  update  transactions  R  and  T.  are  serialized  in  the  order  of  <T.,  T  >  at  the 
confidential  level  backend  database  system.  Since  these  two  transactions  are  update 
transactions,  these  transactions  have  to  be  propagated  to  the  secret  level.  If  these  two 

transactions  are  serialized  in  the  order  of  <T.,  T  >  at  the  secret  level,  an  inconsistent 
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database  state  between  confidential  and  secret  level  backend  databases  may  be  created. 
Therefore,  the  serialization  order  introduced  by  the  local  scheduler  at  the  user’s  session 


level  must  be  maintained  at  the  higher  level  UBDs. 

A  possible  solution  to  problem  [a]  is  presented  in  [10].  In  this  paper  we  concentrate  on  solu¬ 
tions  to  problem  [b] . 


1.2.  Motivation  for  Another  Concurrency  Algorithm 

Several  concurrency  control  mechanisms  which  preserve  database  consistency  and 
security  for  the  replicated  architecture  have  been  proposed  [4,  8,  12].  Those  concurrency 
control  algorithms  assume  that  each  UBD  uses  conservative  scheduling  or  something  simi¬ 
lar  to  preserve  the  scheduled  order  of  conflicting  updates  (i.e.,  never  abort  update  transac¬ 
tions  from  lower  security  classes).  In  reality,  off-the-shelf  database  systems  do  not  gen¬ 
erally  guarantee  this  condition.  Also  such  scheduling  may  either  pass  the  burden  to  the  user 
by  asking  him  to  predeclare  read  and  write  sets  or  remove  the  interactive  query  capability  of 
database  system.  Hence,  this  assumption  poses  performance  and  usability  problems  for  the 
SINTRA  project. 

Also  the  proposed  algorithms  use  the  conventional  basic  operations,  read  and  write,  to 
describe  transactions.  Traditionally,  r[x]  and  w[y]  are  used  to  denote  “read  data  item  x” 
and  “write  data  item  y,”  respectively.  Data  items  x  and  y  may  be  relations,  fixed-sized 
pages,  or  tuples  depending  on  the  granularity  of  concurrency  controllers.  In  this  paper,  we 
propose  a  new  transaction  model  which  is  better  suited  for  the  SINTRA  architecture. 

The  scheduler  for  the  SINTRA  architecture  has  two  kinds  of  components;  global  and 
local.  The  global  scheduler  enforces  data  consistency  among  the  UBDs.  On  the  other  hand, 
the  local  scheduler  enforces  serializability  among  transactions  which  are  submitted  to  the 
backend  database  system.  In  theory,  where  the  global  scheduler  executes  is  not  important  in 
this  architecture.  However,  since  we  expect  that  I/O  will  be  a  bottle-neck  for  this  type  of 
architecture,  we  distribute  much  of  the  single  level  part  of  the  global  scheduler  to  the  back¬ 
end  computers,  depicted  in  figure  1.  The  local  schedulers  are  the  concurrency  controllers  of 
the  off-the-shelf  database  systems. 

The  local  schedulers  typically  use  locks  or  timestamps  based  on  the  knowledge  of 
actual  data  or  physical  layout  of  the  data  in  each  UBD.  However,  the  global  scheduler  has 
very  little  knowledge  about  the  behavior  of  the  local  scheduler  or  the  physical  layout  of 
data.  For  example,  the  global  concurrency  controller  has  no  knowledge  about  where  a 
specific  tuple  is  located  or  which  physical  page  should  be  locked.  Sometimes  the  tuples 
which  will  be  modified  are  unknown  until  the  computation  based  on  existing  data  is  com¬ 
pleted.  The  above  factors  may  force  the  global  concurrency  controller  to  use  relations  as 
basic  units  to  detect  conflicts  among  transactions.  Such  a  scheduler  will  be  too  restrictive 
and  inefficient  because  it  ignores  the  fact  that  referencing  only  a  few  tuples  or  few  attributes 
of  a  relation  is  not  the  same  as  referencing  the  entire  relation. 

Based  on  the  observations  above,  we  argue  that  the  traditional  transaction  model  is  not 
sufficient  to  model  transactions  for  this  replicated  architecture.  In  this  paper,  we  introduce  a 


layered  view  of  transactions.  In  our  model,  a  transaction  can  be  viewed  as  a  sequence  of 
database  queries,  and  each  query  can  be  viewed  as  a  sequence  of  read  and  write  operations. 
Based  on  this  model,  we  introduce  a  concurrency  control  algorithm  which  makes  no 
assumption  that  each  UBD  uses  any  particular  scheduling  technique. 

This  paper  is  organized  as  follows.  Section  2  discusses  a  transaction  model  for  the 
SINTRA  architecture.  A  concurrency  control  mechanism  based  on  this  transaction  model  is 
presented  in  section  3.  Finally,  section  4  summarizes  the  contributions  of  this  paper. 


2.  THE  MODEL 

In  this  section,  models  are  presented  for  security,  replicated  architecture,  and  transac¬ 
tion  processing.  The  transaction  model,  which  is  presented  in  this  section,  can  alleviate  the 
difficulties  described  above  in  section  1.2. 


2.1.  Security  Model 

The  security  model  used  here  is  based  on  that  of  Bell  and  LaPadula  [1].  The  database 
system  consists  of  a  finite  set  D  of  objects  (data  item)  and  a  set  T  of  subjects  (transactions). 
There  is  a  lattice  S  of  security  classes  with  ordering  relation  <.  A  class  S;  dominates  a  class 
Sj  if  Sj  >  Sj.  There  is  a  labeling  function  L  which  maps  objects  and  subjects  to  a  security 
class: 

L:  DuT^S 

Security  class  u  covers  v  in  a  lattice  if  u  >  v  and  there  is  no  security  class  w  for  which  u  >  w 
>  v. 

We  consider  two  mandatory  access  control  requirements: 

(Simple  Security  Property) 

If  transaction  T  reads  data  item  x  then  LIE)  >  L(x). 

(Restricted  *-Property) 

If  transaction  R  writes  data  item  x  then  L(R)  =  L(x). 

The  simple  security  property  allows  a  transaction  to  read  data  items  if  the  security  level  of  a 
transaction  dominates  the  security  level  of  data  items.  The  restricted  *-property  allows  a 
transaction  to  write  if  the  security  level  of  a  transaction  is  the  same  as  that  of  data  items 
(i.e.,  no  write-ups  or  write-downs  are  permitted).  In  [8],  it  is  argued  that  write-ups  (i.e.,  T 
cannot  write  to  data  item  x  if  L(T.)  <  L(x))  are  undesirable  in  database  systems  for  integrity 
reasons. 


2.2.  Replicated  Architecture  Model 

The  system  has  a  TFE,  which  mediates  the  access  of  subjects  to  objects.  The  TFE  con¬ 
tains  the  trusted  computing  base  (TCB),  but  not  all  of  the  TFE  need  to  be  trusted.  The  sys¬ 
tem  also  contains  a  set  of  single  level  untrusted  backend  databases  C,  one  for  each  element 
of  the  security  lattice.  Each  backend  database  Cu  contains  copies  of  all  data  items  in  all 
databases  whose  security  level  is  dominated  by  security  level  u.  Alternatively,  if  L(x)  =  u 
such  that  x  e  C  ,  then  there  is  a  copy  of  x  in  each  database  whose  security  level  dominates 
u. 


2.3.  Transaction  Model 

We  adopt  a  layered  model  of  transactions,  where  a  transaction  is  a  sequence  of  queries, 
and  each  query  can  be  considered  as  a  sequence  of  reads  and  writes.  For  example, 
replace  and  delete  queries  can  be  viewed  as  a  read  operation  followed  by  a  write 
operation,  insert  can  be  viewed  as  a  write  operation,  and  retrieve  can  be  viewed  as 
a  read  operation.  A  layered  view  of  two  transactions  T^  and  T-,  is  shown  in  figure  2. 


Figure  2:  Layered  model  of  two  transactions. 


Definition  1. 

A  transaction  T;  is  a  sequence  of  queries  terminated  by  either  a  commit(c  )  or  an 
abort(a.),  i.e.,  T  =  <q.  |5  q.0,  ...,  q.Q,  c>.  Each  query,  q^,  is  an  atomic  operation  and  is 

one  of  retrieve,  insert,  replace,  or  delete. 

To  model  the  propagation  of  updates  produced  by  a  given  transaction  to  higher  security 
level  databases,  update  projection  is  defined. 


Definition  2. 


An  update  projection  II,  which  corresponds  to  a  transaction  T..  is  a  sequence  of 
update  queries,  e.g.,  II  =  <qi2,  qig,  ...,  qin,  c>  obtained  from  transaction  U  by  simply 
removing  all  retrieve  queries. 

Note  that  no  aborted  transaction  will  be  propagated.  Hence,  update  projections  are  always 
terminated  by  a  commit.  Also  note  that  our  update  projections  consist  of  read  and  write 
operations. 

To  describe  concurrency  control  mechanisms,  we  adopt  the  following  definition  of 
conflict. 

Definition  3. 

Two  operations  at  the  same  layer  conflict  if  they  operate  on  the  same  data  item  and  one 
of  them  is  either  write,  insert,  delete,  or,  replace. 

It  is  interesting  to  compare  our  transaction  model  to  another  multilevel  transaction 
model  which  appears  in  [13].  In  their  model,  the  low-level  conflicts  impose  constraints  on 
the  serialization  orders  for  higher  levels.  However,  in  the  SINTRA  architecture,  the  global 
scheduler  does  not  have  enough  information  about  the  conflicts  which  may  occur  at  the 
local  scheduler.  Therefore,  the  global  scheduler  has  to  make  serialization  decisions  indepen¬ 
dent  of  the  those  of  the  local  scheduler. 

In  the  following  section,  we  present  a  concurrency  control  algorithm  using  the  transac¬ 
tion  model  above.  In  our  concurrency  control  algorithm,  the  global  scheduler  works  at  the 
query  level  (i.e.,  1(1)  in  figure  2). 


3.  A  CONCURRENCY  CONTROL  MECHANISM 

In  this  section,  a  concurrency  control  algorithm  is  presented,  which  makes  no  assump¬ 
tion  about  UBD  scheduling.  In  this  algorithm,  two  types  of  schedulers  can  be  identified, 
global  and  local  schedulers.  The  global  scheduler  enforces  data  consistency  among  different 
security  levels.  On  the  other  hand,  the  local  scheduler  enforces  serializability  among  tran¬ 
sactions,  including  update  projections,  which  are  submitted  to  the  backend  database  system. 
The  local  scheduler  deals  with  layer  1(0)  in  figure  2,  and  the  global  scheduler  deals  with 
layer  1(1)  and  upper  layers.  The  global  scheduler  detects  conflicts  at  level  1(1).  Therefore, 
no  knowledge  of  the  specific  items  to  be  accessed  or  even  the  granularity  of  the  lower  level 
concurrency  controller  is  required. 


3.1.  Algorithm  C 

To  describe  the  concurrency  control  protocol,  we  need  to  define  several  mechanisms: 

•  A  queue  Qu  is  associated  with  each  backend  database  C  ,  where  u  is  a  security  level. 
The  purpose  of  Qu  is  to  maintain  a  list  of  update  projections  which  have  been  executed 
and  committed  at  C  .  The  queue  is  ordered  by  the  serialization  order  of  the  execution 

of  these  transactions  at  C  . 

u 

•  In  addition,  there  is  an  untrusted  mechanism  Ru  which  maintains  Qu  and  can  read  the 
contents  of  Qy  for  all  v  which  are  dominated  by  u  in  the  security  lattice. 

•  Another  queue  Au  is  associated  with  each  backend  database  C  .  The  purpose  of  Au  is 
to  maintain  a  list  of  update  projections  which  come  from  Qy,  where  v  is  covered  by  u, 
and  are  waiting  to  be  sent  to  Cu>  The  order  of  update  projections  in  Au  is  determined 
by  the  concurrency  control  algorithm  which  will  be  described  later. 

In  our  algorithm,  Q  ,  A  ,  and  Ru  are  considered  parts  of  a  global  scheduler.  Since  mechan¬ 
ism  R  has  to  read  the  contents  of  Q  for  all  v  which  are  dominated  by  u,  the  R  and  the  Q 
may  be  located  in  the  TFE.  However,  Au  may  be  located  in  the  backend  system  (see  figure 
1).  Also  in  our  algorithm,  we  say  a  backend  database  Cu  covers  Cy  if  u  covers  v  in  the 
security  lattice.  The  protocol  processes  transactions  as  follows: 

Algorithm  C: 

At  each  backend  database  C  : 

u 

[1]  Primary  transactions  (that  are  submitted  directly  by  the  user)  and  update  projec¬ 
tions  are  received  from  the  global  scheduler  and  submitted  to  the  local  backend 
scheduler. 

[2]  As  local  transactions  (primary  transactions  and  update  projections)  are  commit¬ 
ted,  a  report  of  their  serialization  is  sent  to  the  global  scheduler.  These  reports  are 
sent  in  an  order  consistent  with  the  serialization  order  determined  by  the  local 
scheduler. 

At  the  global  scheduler: 

[1]  For  each  primary  transaction  T.  submitted  to  the  TFE,  T.  is  dispatched  to  Cu  for 
processing  where  L(Tj)  =  u. 

[2]  Whenever  a  serialization  report  for  T.  or  U.  is  received  from  C  ,  it  is  added  to  the 

end  of  Qu.  j 

[3]  The  Ru  scans  the  queue  Qy  for  those  v  for  which  Cu  covers  C  .  The  Ru  will 
retrieve  an  update  projection  U.  from  Qv  and  add  it  to  the  end  of  Au  when  the  fol¬ 
lowing  condition  is  satisfied  for  all  ve  S: 

•  If  Cu  covers  Cy,  and  U.  can  eventually  appear  in  Qy,  then  it  does  appear  in 
the  beginning  of  Qy. 

[4]  For  update  projections  in  the  queue  Au,  update  projections  are  sent  to  Cu  one 
after  another.  Specifically,  if  U.  is  before  U.  in  the  queue  Au,  then  send  U.  and 

wait  until  U.  is  committed  at  C  ,  and  then  send  U.. 

i  u’  j 


[5]  An  update  projection  is  removed  from  Au  once  it  is  committed. 

[6]  If  an  update  projection,  U.,  is  aborted  then  resubmit  U.  to  Cu. 

In  algorithm  C,  we  assume  that  local  schedulers  produce  schedules  such  that  the  serializa¬ 
tion  order  and  the  commit  order  of  transactions  are  the  same2  (i.e.,  for  any  pair  of  transac¬ 
tions  T.  and  T.,  if  T.  is  committed  before  T.  then  T.  also  precedes  T.  in  the  serialization 
order).  However,  most  database  schedulers  do  not  guarantee  the  above  condition.  The 
take-a-ticket  [7]  operation  can  be  used  to  force  any  recoverable  scheduler  [2]  to  produce 
schedules  such  that  the  serialization  order  and  the  commit  order  of  transactions  are  the 
same.  The  take-a-ticket  operation  consists  of  reading  the  value  of  a  ticket  prior  to  commit 
time,  and  incrementing  it  through  regular  data  manipulation  operations.  The  value  of  a 
ticket  determines  the  serialization  order.  All  operations  on  tickets  are  subject  to  the  local 
concurrency  control. 

Note  that  algorithm  C  does  not  slow  down  user  (primary)  transactions.  The  global 
scheduler  of  algorithm  C  concerns  the  serialization  order  of  the  update  projections  in  A  at 
each  security  level.  Concurrency  control  among  primary  transactions  and  update  projections 
is  the  responsibility  of  the  local  scheduler  in  the  UBD. 

Also  note  that  Qu  and  Ru  are  not  needed  if  the  security  classes  form  a  completely 
ordered  set,  since  Au  satisfies  all  the  requirement  of  the  algorithm. 


3.2.  Proof  of  Correctness 

Many  concurrency  control  algorithms  have  been  proposed  for  the  replicated  architec¬ 
ture  [4,  8,  12].  These  papers  use  one-copy-serializability  (or  1  SR)  [2]  as  the  correctness  cri¬ 
teria  for  their  concurrency  control  algorithms.  In  this  paper,  we  present  an  alternative 
correctness  criteria  which  we  consider  more  intuitive.  Based  on  this  criteria,  we  will  prove 
that  algorithm  C  is  correct.  We  will  then  show  that  our  criteria  imply  one-copy- 
serializability. 

For  the  sake  of  mathematical  convenience,  in  this  section,  we  assume  read-only  tran¬ 
sactions  have  empty  update  projections  which  serve  solely  to  mark  their  position  in  the  seri¬ 
alization  ordering  of  all  transactions.  Also,  in  this  section,  we  do  not  distinguish  the  queue 
Qu  at  the  security  class  u  and  the  contents  of  update  projections  in  the  queue  Qu. 

An  example  will  help  to  clarify  our  approach.  Consider  the  security  lattice  in  figure  3, 
and  two  non-conflicting  L-level  transactions  Ti  and  T..  Also  consider  an  Ml-level  transac¬ 
tion  T  ,  and  an  M2-level  transaction  T  .  Let’s  further  assume  that  T  conflicts  with  T.  and 
u’  v  u  1 

Tj,  and  Ty  conflicts  with  T.  and  T..  Since  two  transactions,  C  and  H,  are  not  conflicting  and 

2.  Consider  the  history  of  two  transactions,  T.  and  T.,  H,  where  H  =  r. [x]  w^x]  r.[x]  Wj[x]  w^y] 
c.  Cj.  This  history  does  not  satisfy  the  rigorousness  condition  [3].  However,  this  history  will 
be  satisfactory  for  our  purpose  because  the  serialization  order  and  the  commit  order  of  tran¬ 
sactions  are  the  same. 


our  security  model  does  not  allow  write-down ,  an  execution  order  <T\,  Tu,  T>  at  security 
class  Ml  and  an  execution  order  <T.,  Ty,  T(>  at  security  class  M2  will  generate  the  same 
result  on  replicas  of  security  class  L  data.  However,  the  reversed  order  between  T\  and  T.  at 
security  classes  Ml  and  M2  will  create  confusion  in  applying  our  update  projection  propa¬ 
gation  rule.  Specifically,  at  security  class  H,  a  consistent  ordering  among  T\,  Tj,  Tu,  and  Ty 
cannot  be  determined  then  1SR  will  be  violated.  Consequently,  any  global  scheduler  which 
does  not  enforce  the  same  ordering  among  transactions  at  each  relevant  UBD  may  fail  to 
produce  consistent  schedules.  Thus  any  algorithm  which  gives  1SR  schedules  must  preserve 
the  orderings  at  lower  levels. 


<T  ,  T  ,  T  >  Ml 


M2  <T  ,  T  ,  T  > 


<T.,  T  > 
i  J 


H  >  Ml  >  L 
H  >  M2  >  L 


Figure  3:  A  security  lattice 


In  this  paper,  we  use  another  criteria  which  says  ‘  ‘preserve  the  order  between  update 
projections  which  is  determined  at  lower  security  class  (or  preserve  the  relative  order).”  We 
also  show  that  any  schedule  for  this  architecture  which  preserves  the  relative  order  of  update 
projections  satisfies  1SR. 

sj: 

Let  U  =  {  Uj  |  Tj  e  T}  be  the  set  of  all  update  projections  and  U  be  the  set  of  all 
strings  from  U.  Then  for  each  pair  of  security  classes  u  and  v  of  S,  for  which  u  >  v,  there  is 
a  projection  7tuy  :  U  — >  U  which  is  defined  as  follows: 

(a)  7t  (U.)  =  U.  if  L(T.)  <  v. 

v  '  UV  v  V  1  v  V 

(b)  7luy  (Uj)  =  X,  the  null  string,  otherwise. 

Definition  4. 

If  u  and  v  are  in  S,  with  u  >  v,  and  7tuy  (Qu)  =  Qv  then  we  say  that  the  relative  order 
between  Qu  and  Qy  is  preserved. 

For  example,  if  Qu  =  <Uj,  Uk,  U>  and  Qy  =  <Uj,  U>,  and  Uk  is  originated  from  security 
class  w,  where  u  >  w  >  v,  then  the  relative  order  of  update  projections  in  Q  and  Q  is 
preserved  because  7tuy  (Qu)  =  Qy  =  <U,  U>.  We  can  now  state  our  concept  of  correctness 


for  transaction  processing  more  precisely. 


Definition  5. 

For  replicated  architecture  trusted  database  systems  as  above,  let  Qu  be  the  serializa¬ 
tion  order  of  the  transactions  and  update  projections  committed  at  C  .  Then  a  con¬ 
currency  control  algorithm  is  correct  if  it  preserves  relative  orders  for  all  elements  of 
the  security  lattice. 

Theorem  1 

Algorithm  C  is  correct. 

Proof. 

This  is  evident  from  the  algorithm,  since  at  each  class,  the  update  projections  are  executed 
and  committed  in  the  same  relative  order  established  at  lower  security  class.  □ 

Briefly,  a  schedule  of  transaction  execution  on  a  replicated  database  system  is  one- 
copy-serializable  if  it  is  view  equivalent  to  a  serial  schedule  on  a  one-copy  database  sys¬ 
tems.  View  equivalence  requires  the  two  schedules  to  have  the  same  reads-from  and  final- 
writes  relationships.  Details  for  this  architecture  may  be  found  in  [4].  Such  schedules  will 
be  referred  to  as  ML-1SR.  Although  in  the  following  proofs,  we  use  only  read  and  write 
operations,  we  could  instead  use  retrieve,  insert,  replace,  and  delete  as  in 
our  query  languages.  We  denote  read  and  write  operations  on  a  data  item  x,  or  a  copy  of  it 
x  ,  of  transaction  D,  by  r[x]  and  w^xj. 

Theorem  2 

With  the  architecture  as  specified  above,  if  each  UBD  has  a  local  scheduler  which  pro¬ 
duces  serializable  schedules  and  there  is  a  global  scheduler  such  that  for  all  u  and  v 
with  u  >  v,  the  relative  order  between  Q  and  Q  is  preserved,  then  the  global  schedule 

is  ML-1SR. 

Proof. 

Let  S  ,  where  m  is  the  maximal  element  of  the  security  lattice,  determine  a  serial  execution 
order  on  the  one-copy  logical  database  corresponding  to  the  replicated  system,  and  let  H  be 
the  schedule  produced  by  an  algorithm  satisfying  the  hypotheses  of  the  theorem.  We  assert 
that  H  is  view  equivalent  to  S  .  Clearly,  H  and  Sm  have  the  same  final-writes,  by  definition 
of  S  .  We  will  show  that  H  and  Sm  have  the  same  reads-from  relationships  using  proof  by 
contradiction. 

(1)  Suppose  D  reads-x-from  D  in  Sm,  but  not  in  H.  Let  L(T.)  =  n.  Then  in  Cu,  Wj[x]  pre¬ 
cedes  wk[x]  and  wk[x]  precedes  r[xj.  But  then  at  Qu,  the  serialization  order  is  T  pre¬ 
cedes  Tk  and  Tk  precedes  T..  This  is  preserved  in  Sm,  by  hypothesis,  contradicting  that 

T.  reads-x-from  T.  in  S  . 

J  i  m 


(2)  Suppose  Tj  reads-x-from  T\  in  H,  but  not  in  Sm>  Then  if  L(Tj)  =  n,  T.  reads-x-from  R 
in  Cu.  But  if  there  is  a  Tk  for  which  Wj[x]  precedes  wk[x]  and  wk[x]  precedes  r[x]  in 
Sm,  then  because  L(Tk)  =  L(Tj)  =  L(x)  <  n,  this  relationship  also  holds  in  Cu  and  thus 
in  H.  This  contradicts  our  assumption  that  T.  reads-x-from  D  in  H.  □ 

It  is  worthwhile  to  note  that  if  the  system  has  a  completely  ordered  security  lattice,  the  rela¬ 
tive  order  between  non-conflicting  update  projections  does  not  have  to  be  preserved.  It  is 
sufficient  to  preserve  the  ordering  of  conflicting  update  projections,  rather  than  all  update 
projections.  This  may  permit  greater  concurrency. 

Corollary  1 

Algorithm  C  produces  ML-1SR  schedules. 

Proof. 

This  follows  immediately  from  the  preceding  theorems.  □ 


3.3.  Two  Variations 

Step  [4]  of  algorithm  C  forces  update  projections  to  execute  serially.  However,  if  the 
global  scheduler  of  the  SINTRA  system  can  detect  conflicts  among  transactions,  we  can 
achieve  better  concurrency  among  update  projections  by  taking  advantage  of  this 
knowledge.  Since  the  backend  database  system  usually  cannot  report  whether  there  were 
conflicts,  an  accurate  analysis  technique  which  can  detect  conflicts  among  transactions  is 
needed.  Data  dependence  analysis,  introduced  in  [9],  can  detect  conflicts  among  transac¬ 
tions  without  any  knowledge  of  actual  data  or  physical  layout  of  data.  Rather,  it  relies  on 
analysis  of  the  queries  themselves,  detecting  conflicts  by  determining  if  common  data  is  to 
be  accessed. 

The  rest  of  the  section  introduces  two  variations  of  the  algorithm  C,  optimistic  and 
semi-optimistic  approaches,  which  may  achieve  better  concurrency.  These  variations  are 
concerned  with  how  update  projections  in  Au  are  submitted  to  the  UBD,  and  therefore  how 
committed  user  transactions  and  update  projections  are  placed  in  Q  .  In  our  two  variations, 
transactions  are  executed  hoping  that  the  “correct”  schedule  is  produced.  When  it  is  not, 
some  amount  of  work  already  done  will  have  to  be  undone.  Hence,  processing  that  is  com¬ 
pleted  will  have  to  be  certified  before  it  can  be  committed. 

For  the  rest  of  the  section,  we  assume  that  the  serialization  order  is  known  at  the  end  of 
each  transaction  (just  before  it  might  be  committed).  No  transaction  may  actually  be  com¬ 
mitted  unless  the  global  scheduler  certifies  it.  If  a  user  transaction  or  an  update  projection  is 
committed,  then  it  will  be  dispatched  to  Q  .  However,  if  a  user  transaction  or  an  update  pro¬ 
jection  is  executed  but  not  yet  committed,  the  global  scheduler  will  store  it  in  a  queue  Pu. 
P  holds  candidates  for  insertion  into  Q  .  Once  the  global  scheduler  certifies  and  commits  a 

transaction  then  it  will  be  moved  from  P  to  Q  . 

u 


3.3.1.  Optimistic  Approach 


Generally,  the  optimistic  variation  of  the  algorithm  C  works  as  follows.  User  transac¬ 
tions  and  update  projections  at  any  security  level  are  submitted  to  the  backend  as  they 
arrive.  If  an  update  projection  is  completed  out  of  the  submission  order,  it  is  held  in  Pu 
awaiting  certification,  along  with  the  completed  user  transactions  submitted  at  that  level. 
When  an  update  projection  which  is  submitted  earlier  completes  and  is  placed  in  Pu,  data 
dependence  analysis  is  used  to  determine  whether  the  serialization  order  determined  by  Pu 
is  equivalent  (in  a  technical  sense)  to  a  correct  (update  order-preserving)  one.  If  it  is,  Pu  is 
rearranged  to  get  a  maximal  prefix  which  is  correct.  The  transactions  in  the  prefix  are 
certified  and  committed.  If  Pu  cannot  be  rearranged,  all  transactions  in  Pu  must  be  rolled 
back  and  re-submitted. 


More  specifically,  the  optimistic  approach  works  as  follows: 


[a]  Submit  update  projections  in  Au  to  UBD  as  they  arrive. 

[b]  Commit  user  transactions  and  update  projections  as  long  as  update  projections  are  seri¬ 
alized  in  the  order  that  they  are  submitted  to  UBD  up  to  that  time  (i.e.,  Pu  is  empty). 
Once  those  are  committed  then  dispatch  them  to  Qu. 

[c]  If  Uj  should  be  next  to  be  serialized  but  U.  is  already  serialized  then  put  U.  in  Pu 

without  committing  it.  Any  user  transactions  or  update  projections  which  are  executed 

will  be  put  in  Pu  without  committing  them  until  U  is  executed.  After  U  is  executed, 

put  U.  into  P  . 
r  1  u 

[d]  While  the  first  and  last  transactions  in  Pu  are  update  projections,  do  the  following 
steps: 

(1)  Find  an  update  projection  in  Pu  which  should  be  serialized  before  any  other 
uncommitted  update  projections.  Call  that  update  projection  T  . 

(2)  Test  if  the  first  transaction  in  Pu,  T(  (which  must  be  an  update  projection), 

conflicts  with  T  .  If  T,  and  T  conflict  then  abort  and  remove  all  transactions  in 
n  1  n 

Pu,  re-submit  them,  and  return  to  [a]. 

(3)  Test  if  Tj  conflicts  with  any  of  the  transactions  from  T-,  through  Tn  j.  If  there  is 
no  conflict,  then  move  Tj  to  immediately  after  Tn  in  Pu  and  go  to  step  (5). 

(4)  Test  if  Tn  conflicts  with  any  of  the  transactions  from  T0  through  Tn  j .  If  there  is  a 
conflict,  then  abort  and  remove  all  transactions  in  P  ,  re-submit  them,  and  return 
to  [a].  Otherwise  move  Tn  to  the  beginning  of  Pu. 

(5)  While  the  first  transaction  in  Pu,  T(,  is  either  a  user  transaction  or  an  update  pro¬ 
jection  which  is  in  the  proper  order  to  be  serialized  then  do  the  following  steps: 

•  Commit  Tj,  remove  it  from  Pu  and  Au  if  applicable,  and  dispatch  it  to  Qu. 


An  example  of  this  may  be  helpful.  Consider  a  situation  where  the  global  scheduler  submits 
update  projections  in  the  order  of  <Ui?  Uj>  and  the  serialization  order  at  the  UBD  is  <U,  Tk, 
U  >  where  T,  is  a  user  transaction.  Since  U.  is  serialized  before  U.,  U.  cannot  be  committed 

i  k  j  i  j 

until  U-  is  committed.  Now  the  task  is  to  find  if  the  order  of  either  U-  or  U.  can  be  rear- 
i  i  J 

ranged.  The  only  way  this  can  happen  is: 


•  There  is  no  conflict  between  U.  and  U-,  and  either 

i  J 

(a)  There  is  no  conflict  between  T_L  and  Tk,  or 

(b)  There  is  no  conflict  between  Tk  and  II. 

If  situation  (a)  happens  then  <Tk,  Up  U>  will  be  the  order  which  will  be  sent  to  Qu  by  the 
algorithm.  If  situation  (b)  happens  then  <11.  U,  Tk>  will  be  the  order  which  will  be  sent  to 
Q  .  This  more  complex  approach  may  be  justified  if  conflicts  are  likely  to  occur  more  fre¬ 
quently. 

We  could  improve  the  performance  of  this  algorithm  by  minimizing  the  number  of 

transactions  which  must  be  aborted.  For  example,  assume  that  T(  and  Tn  do  not  conflict  but 

Tj  conflicts  with  Tk  and  Tn  conflicts  with  Tk+1>  We  could  just  abort  Tk+1  through  Tn  to 

ensure  that  T  is  serialized  before  T,  . . 

n  k+1 


3.3.2.  Semi-optimistic  Approach 

Since  the  SINTRA  security  policy  prohibits  write-up  or  write-clown ,  the  probability  of 
conflict  between  a  user  transaction  at  security  class  u  and  an  update  projection  from  the 
security  class  v  where  u  >  v  may  be  quite  small3.  Hence  if  conflicts  among  update  projec¬ 
tions  are  detected  before  those  are  submitted  then  there  is  less  probability  of  aborting. 

The  semi-optimistic  variations  is  similar  to  the  optimistic  one,  but  rather  than  submit¬ 
ting  update  projections  as  they  arrive,  it  checks  for  conflicts  first,  thereby  reducing  the  likeli¬ 
hood  of  having  to  roll  back  work  already  done.  Specifically,  the  semi-optimistic  approach 
replace  the  step  [a]  of  the  preceding  optimistic  approach  with  following: 

[al]  Detect  conflicts  among  update  projections  in  Au. 

[a2]  If  two  update  projections  U  and  U  conflict  then  submit  them  serially  (i.e.,  submit  one 
and  then  wait  for  a  commit  message  before  submitting  another). 

[a3]  If  there  are  update  projections  in  Au  which  do  not  conflict  then  submit  one  after 
another  (i.e.,  submit  one  and  then  submit  next  update  projection  without  waiting  for 
commit  message  of  previous  update  projection). 

After  applying  steps  [b]  and  [c]  of  the  optimistic  approach,  Pu  can  be  tested,  as  before  (i.e., 
step  [d]  of  optimistic  approach).  The  only  difference  is  that  there  is  no  need  to  detect 
conflicts  among  update  projections  because  those  have  been  already  tested.  Therefore,  only 
steps  (1),  (3),  (4),  and  (5)  from  the  optimistic  approach  are  required.  This  technique  clearly 
falls  between  those  of  the  previous  two  algorithms.  The  following  table  clarifies  the  dif¬ 
ferent  approaches  of  the  three  variations. 


3.  The  SINTRA  security  policy  allows  read-down.  Hence,  a  user  transaction  at  level  u  can 
conflict  with  an  update  projection  from  level  v  where  u  >  v. 


Algorithm  Variant 

Submission  Process  for 
Update  Projections 

Mechanism  for  Insuring  Consistent 
Update  Projection  Ordering 

Pessimistic 
(Algorithm  C) 

One  at  a  time 

None  required 

Semi-optimistic 

Check  for  conflicts  be¬ 
fore  submitting.  Main¬ 
tain  submission  order 
for  conflicting  update 
projections. 

Check  for  conflicts  between  update 
projections  and  primary  transac¬ 
tions  after  execution.  Roll  back 
and  redo  as  necessary. 

Optimistic 

As  they  arrive  (No 
checking  or  delaying) 

Check  for  conflicts  among  all  local 
transactions  after  execution.  Roll 
back  and  redo  as  necessary. 

3.3.3.  Correctness  of  the  Variations 


Corollary  2 

The  Optimistic  and  semi-optimistic  variations  of  algorithm  C  produce  ML-1SR 
schedules. 

Proof. 

This  is  evident  from  the  algorithm,  since  the  global  scheduler  certifies  a  schedule  only  if  the 
relative  order  between  Qu  and  Qy  is  preserved  for  all  u  and  v  with  u  >  v.  □ 


4.  CONCLUSIONS 

In  this  paper,  we  have  presented  arguments  that  the  traditional  transaction  model  is  not 
sufficient  to  model  transactions  for  multilevel-secure  databases  which  use  the  replicated 
architecture.  We  have  proposed  a  new  transaction  model  for  multilevel-secure  databases. 

Even  though  several  concurrency  control  algorithms  for  the  replicated  architecture 
have  been  proposed,  those  algorithms  assume  that  each  UBD  uses  conservative  scheduling 
or  at  least  assumes  schedules  preserve  the  order  of  update  projections  without  indicating 
how  it  is  done.  We  present  a  concurrency  control  algorithm  which  does  not  assume  that 
each  UBD  uses  conservative  scheduling.  Our  concurrency  control  algorithm  is  based  on  the 
transaction  processing  model  which  is  proposed  in  this  paper,  which  controls  ordering 
through  other  means,  outside  the  UBD. 

Our  basic  concurrency  algorithm,  algorithm  C,  executes  update  projections  serially. 
We  also  offer  two  variations  of  algorithm  C,  optimistic  and  semi- optimistic  approaches, 


which  may  achieve  better  concurrency  under  a  variety  of  likely  conditions.  Our  directions 
for  future  research  are  performance  comparison  among  different  variations  under  different 
application  scenario.  These  algorithms  are,  in  fact,  being  implemented  in  our  prototype  for 
the  SINTRA  project. 
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